The process of developing software applications involves a structured approach designed to enhance the quality of the finished product. The structured approach to software application development involves a series of stages known as a software application development life cycle. There are several different implementations of the software application development life cycle, but in general, the process of software application development begins with analysis of the needs of an end user, such as a corporation, governmental entity, private individual, etc. The next stage involves designing the software application to meet the needs of the end user, after which the software application itself is created. After testing the software application, the software application is then sent to the end user. Corrective maintenance of, and improvements to, the software application may continue after sending the software application to the end user. Adherence to a structured approach of software application development decreases the number of flaws in the finished software application product.
A bug is generally defined as some flaw in the software application that causes all or some portion of the software application to malfunction or to perform in some unexpected fashion. As the commercial software application marketplace demands ever more powerful and feature-rich software applications, and as the complexity of software applications increases, the number of bugs increases. Although the structured approach to software application development is designed to prevent bugs, software application developers are not perfect and have a limited capacity to deal with complexity, and so therefore mistakes leading to bugs are inevitable. Many bugs are difficult to find and remain hidden until discovered by the end user.
In order to address the problem of bugs that exist in software which is already released to users, software manufacturers often release new versions of software applications in which bugs have been fixed. The users may then obtain the new versions. However, fixing bugs in software applications that have already been released is often costly.
In order to improve software application quality, software application manufacturers may employ bug-tracking systems. Bug-tracking systems help software application manufacturers find out what bugs are in the software application while the software application is being developed or tested prior to release, or after the software application has been released to the end user. Software application developers, software application testers, end users, or other interested parties may report bugs to the bug-tracking system by various means, such as telephone, email, etc. The software application manufacturer then collects reported software application bugs and stores the details of the reported bugs for analysis. Each bug is assigned a unique value, and the bug-tracking system thereby facilitates the fixing of bugs by allowing the software application manufacturer to monitor the progress of fixing the bug.
Independent Software Vendors (ISV's) are software application manufacturers that develop, or are involved with, software applications designed to enhance, improve upon, or work in conjunction with, other software applications developed by—or hardware developed by—another manufacturer. For example, an ISV may create an end user software applications designed to function on a certain computer operating system, such as a database management system meant to run on a computer operating system. ISV-created software applications is often referred to as “third party software applications.” The abundant existence of third party software applications for a software application such as an operating system enhances the value of the operating system for the end user by providing the end user with more choice and functionality in third party software applications for the operating system.
The presence of bugs in the operating system may hinder the development of third party software applications for that operating system. Third party software applications developed specifically for some other software application, such as an operating system, is by nature dependent upon the design of the operating system. Bugs in the operating system may make development of third party software difficult, or may deter ISV's from developing third party software applications for the operating system because of the added cost of dealing with the bugs. Furthermore, bugs in the operating system may also result in lower performance, thereby making the operating system less attractive to users.
A downstream ISV develops third party software applications that depend upon or work in conjunction with other third party software applications developed at some other ISV. For example, an ISV (company “A”) may develop a web browser designed to operate on a certain operating system. Another ISV (company “B”) may develop a software application that depends upon or works in conjunction with the web browser. Company “B” is known as a “downstream ISV.”
A bug advocate is a name given to employees of software application manufacturers appointed the task of eliminating bugs reported to the software application manufacturer by end users, in-house developers, developers working for ISV's, or other interested parties. The bug advocate, through the use of a bug-tracking system, follows through on some or all of the reported bugs, ensuring that bugs are rated and fixed. Thus, the use of the bug advocate and bug-tracking systems by software application manufacturers enhances the quality of the software application by facilitating the process of fixing bugs. Software application quality is enhanced by delivering a better product to the end user, and also by delivering better software applications to the ISV's. The ISV's are then better able to develop third party software applications, which, in turn, makes the software application more attractive to the end user by giving the end user more choice and functionality in third party software applications.
The foregoing statements regarding the problems of bugs in software application development also generally apply to other types of manufacturing besides software application manufacturing. For example, the manufacturers of computer hardware also address flaws in the finished product in order to facilitate the development of third party software applications meant to operate in conjunction with the computer hardware. Furthermore, any entity that creates a commercial product deals with the problems of quality control.
Java™ is a computer language designed by Sun Microsystems, Inc. (“Sun Microsystems”, hereinafter) to allow creation of software applications to run on various computer platforms. Referring to FIG. 1, in order to create a Java™ software application, the developer first writes the software application in human-readable Java™ source code. As used herein, the term “software application” refers to Java™ 2 Standard Edition (J2SE™) software applications and Java™ “applets” which are essentially small software applications usually embedded in a web page. In the example shown, the software application “Program” (11) is created as a human-readable text file. The name of this text file is given the required five-character extension “.java.” The Java™ compiler (“javac”, “fastjavac”, “jvc”, et. al.) (13) is used to compile the source code into a platform independent bytecode (15). Upon compilation, the resulting binary file (15) will automatically receive the same file name as the source text file with “.class” extension or the same name of the source file plus a special character “$” plus the name of an inner class with the extension “.class.”
The Java™ runtime environment incorporates a virtual machine (16) to verify whether a given bytecode (15) has the proper format (verification process) and convert the “.class” byte codes into actual machine executions (17). The machine executions (like drawing windows, buttons, and user prompt fields) will occur in accordance to the software application developer's code instructions. Because Sun Microsystems specifically designed the virtual machine (16) to run on different platforms, a single set of “.class” byte codes will execute on any platform where a virtual machine (16) has been installed. An Internet web browser such as Netscape® and Microsoft® Internet Explorer that incorporates a virtual machine (16) is called a “java-enabled” web browser. A discussion of the Java™ language itself is beyond the scope of this document. However, complete information regarding the Java™ programming language and the Java™ platform are available from Sun Microsystems both in print and via the Internet at http://wwwjava.sun.com.
Servlets are software applications that run on a web server through the virtual machine. Servlets deliver HTML web pages to a web browser client. The web browser client requests HTML web pages from the server, and the servlet responds by creating an HTML web page, which the server sends back to the web browser client. Servlets allow the server to respond to deliver web pages dynamically, i.e., the content of the HTML web page may vary from client to client, the client web browser may interact with the servlet, etc. Thus, the servlet may create web pages based upon input from the user operating the web browser client. Examples of dynamic content are e-commerce applications, online tutorials, etc.
In order to respond dynamically to the web browser client, the servlet often makes use of a database. The database is a repository of information stored in computer memory, accessible to a variety of software applications. The servlet is connected to the database via a computer network; the web browser client is also connected to the server and servlet via a computer network. A typical sequence of operations is illustrated in FIG. 2. The web browser client (30) sends a request (32) to the server (34). The server (34) passes the request (32) to the appropriate servlet (36), which then performs needed processing. The servlet then interacts (37) with the database (38), either writing to or reading from the database (38). The server then responds (39) to the web browser client (30).